Microsoft Windows Network Virtual Device Drivers in 
PATHWORKS for DOS 



Digital's PATI-IWORKS for DOS version 4.1 personal computer integration software 
includes two network virtual device drivers for the Microsoft Windows environment. 
These drivers allow Windows applications operating in a protected processor mode 
and standard DOS applications in a virtual machine to concurrently access services 
designed to run in real mode under the DOS operating system. The network virtual 
device drivers, available only in IVIicrosoft Windows enhanced mode, manage 
DECnet and NetBIOS operations and permit the full use of these interfaces 



By Andrew W. Nourse 



Introduction 

Microsoft Windows virtual device drivers are load- 
able software modules that extend the Windows op- 
erating system and enable it to support peripheral 
devices, memory resources, and software applica- 
tions. Some of these modules allow applications 
that operate in different processor modes with cor- 
responding differences in memory access to commu- 
nicate with one another in a network system. Digi- 
tal's PATHWORKS products make it possible to in- 
tegrate personal computers into local or wide area 
network systems. The PATHWORKS for DOS soft- 
ware includes two network virtual device drivers, 
which manage DECnet and network basic I/O sys- 
tem (N etB I OS) operati ons i n the M i crosoft Wi ndows 
environment for PCs. 

This paper begins with a discussion of the Mi- 
crosoft Windows environment for which the PATH- 
WORKS for DOS product provides network virtual 
device drivers. The basic processor operating modes 
and Microsoft Windows operating modes are de- 
scribed, preparatory to an explanation of Microsoft 
Windows enhanced mode. This explanation is es- 
sential because virtual device drivers operate only 
in enhanced mode. 

Next, the paper details the capabilities of virtual 
device drivers, such as providing the means for Win- 
dows and DOS applications to communicate. The 
focus then turns to the environment for developing 
Microsoft Windows virtual device drivers and con- 
dudes with a description of the structure and func- 
tionality of the two network device drivers included 
in the PATHWORKS for DOS software. 



Microsoft Winders Environment 

The Microsoft Windows environment is a graphi- 
cal, multiapplication system for personal computers 
that use the Intel 80286 or higher microprocessor. 
F or 80286-based systems, the Wi ndows system op- 
erates in its standard mode, using the real and pro- 
tected processor modes. On the 80386 or higher mi- 
croprocessor, the Windows system can also operate 
in its enhanced mode, using both protected and vir- 
tual processor modes. Enhanced mode allows the 
Windows system to fully utilize processor features 
such as virtual memory and multiple virtual ma- 
chines. Virtual device drivers are available only in 
this enhanced mode. 

Basic Processor Operating Modes 

All members of the 80x86 family, including the 
80386 microprocessor, calculate addresses in mem- 
ory by using a segment register and an offset. How- 
ever, the method for calculating the physical address 
varies, depending on the processor mode. The basic 
processor operating modes are real mode, protected 
mode, and virtual mode. 

Real Mode This mode is used by the DOS oper- 
ating system exclusively and by most DOS applica- 
tions. The processor calculates physical addresses 
by shifting the contents of a 16-bit segment register 
left by 4 bits and adding a 16-bit offset. Therefore, 
only the first 1 megabyte (MB) plus 65,519 bytes of a 
PC's physical memory are directly accessible in this 
mode. 

The basic layout of PC memory is shown in Figure 
1. The first megabyte of physical memory is known 
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as cxjnventional memory. This area may include the 
PATHWORKS implementation of the DECnet trans- 
port protocol, namely the DECnet Network Process 
component, as well as other memory-resident soft- 
ware. In addition, conventional memory may con- 
tain the DOS operating system and DOS applica- 
tions. The next 65,519 bytes are called the high 
memory area. Bank-switched memory, known as 
expanded memory, may also be available. In real 
mode, memory protection and virtual memory are 
not available, illegal instructions are generally ig- 
nored, and I/O instructions are always allowed. 
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Figure 1 Basic PC Memory Layout 



Protected Mode In this mode, a segment register 
contains a selector. Part of the selector is an index 
into a descriptor table maintained by the hardware. 
A flag in the selector indicates which of two descrip- 
tor tables to use, the local descriptor table or the 
global descriptor table. The processor adds the off- 
set to the I i near address obtai ned from the appro- 
priate descriptor table. The 80386 implementation 
differs from that of the 80286 because the 80386 
processor offers both 16- and 32-bit general regis- 
ters and offsets, whereas the 80286 processor has 
16-bit general registers and offsets. 



In protected mode, if paging is disabled, the linear 
address is the physical address. If paging is en- 
abled, the linear address is decoded into a page di- 
rectory entry, a page table entry, and an offset. The 
page directory entry identifies a page table, and the 
page table entry provides a physical address. 

Protected mode is used by applications that use 
DOS extenders to access memory beyond that which 
is accessible from real mode. 80386 processors op- 
erating in protected mode may use virtual memory. 
In this mode, an illegal instruction causes a pro- 
cessor trap, and I/O instructions may be selectively 
allowed or trapped. 

Virtual Mode This mode implements a virtual 
machine that emulates the behavior of an 8086 mi- 
croprocessor. Address calculation in this mode is 
similar to that in real mode, except that in virtual 
mode the result of the shift-and-add operation is a 
linear address. The processor converts this address 
to a physical address, as in protected mode. Pro- 
cessors operating in virtual mode may use virtual 
memory. Also, each virtual machine can have a sep- 
arate page di rectory, an illegal instruction causes a 
processor trap, and I/O instructions may be allowed 
or trapped. 

M icrosoft Wi ndows Operati ng M odes 

The M i crosoft Wi ndows envi ronment supports sev- 
eral operati ng modes. 

Windows Real Mode Similar to previous versions 
of the Wi ndows system, Wi ndows 3.0 can operate i n 
real mode, i.e., use conventional memory, ©(panded 
memory, and the high memory area. This mode is 
not supported in Windows 3.1. 

Windows Standard Mode. Windows 3.0 and 3.1 
can operate i n standard mode on the 80286 or hi gher 
microprocessor. This mode uses the protected pro- 
cessor mode, but does not take advantage of the 
32-bit features of the 80386 processor. The Win- 
dows system and Windows applications are located 
outside conventional memory, except for code neces- 
sary to provide the communication links with DOS 
and other resident software. Standard DOS appli- 
cations run in real mode and occupy the full screen, 
as if the Windows system were not present. Switch- 
ing between Windows and non-Windows applica- 
tions is accomplished by performing a sequence of 
keystrokes in exactly the same manner as under the 
MS-DOS version 5.0 task switcher. Virtual device 
drivers are not used in standard mode. 

Windows Enhanced Mode In enhanced mode, 
the Microsoft Windows system provides each non- 
Windows application a virtual machine in which to 
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operate. These machines are preemptively multi- 
tasl<ed, so even cjompute-bound, non-Windows ap- 
plications can run in the background. The Windows 
system and all Windows applications share a single 
virtual machi ne so they can communicate with each 
other. 

The Microsoft Windows system uses the protected 
and virtual modes of the 80386 processor. Paging is 
always enabled. The first 1MB plus 65,519 bytes of 
the linear address space is mapped to the first 1MB 
pi us 65,519 bytes of memory bel ongi ng to the vi rtual 
machine currently executing. This mapping allows 
each DOS application its own block of memory in 
which to run. 

Some data must be shared among the vi rtual ma- 
chi nes. Whenever all or most of the data in a page 
is shared, a global page is used. Most resident soft- 
ware that was loaded before the Windows system 
start-up is stored in global pages. Selected data 
within these global pages may be maintained sep- 
arately for each virtual machine. This practice is 
called instancing and may be requested by the res- 
ident software. 

To support operations requested by virtual ma- 
chines, virtual device drivers extend the Microsoft 
Windows kernel. The drivers are loaded at Windows 
initialization and effectively become part of the ker- 
nel. 

The Microsoft Windows enhanced mode kernel 
uses 32-bit registers and offsets. The segment reg- 
isters are loaded with selectors that allow access 
to all of memory when the kernel is operating and 
eliminate the need to break code and data into 64- 
kilobyte (KB) segments of memory. This memory 
model is known as the flat model. 

Although the Windows enhanced mode kernel is 
written to use 32-bit registers and offsets, most of 
the remaining libraries supplied with the Windows 
system and nearly all applications are written to use 
16-bit registers and offsets. The Windows applica- 
tions run in protected mode, whereas virtual mode 
provides support for the DOS applications, which 
need not even be aware that the Wi ndows envi ron- 
ment exists. 



Virtual Device Driver Capabilities 

Virtual device drivers provide the means for Win- 
dows and DOS applications to communicate, sup- 
port asynchronous operations, virtualize hardware 
ports and interrupts, and directly handle hardware 
and software interrupts. These capabilities are de- 
scribed in the following section. 



Communication between Protected-mode and Real- 
mode Software AppI icati ons 

A virtual device driver provides a bridge between 
Windows applications running in protected mode 
and DOS terminate and stay resident (TSR) applica- 
tions written to run in real mode with no knowledge 
of protected mode. A Windows application that calls 
an application programming interface (API) passes 
it a valid protected-mode address. Without virtual 
device drivers, the real-mode software would inter- 
pret this address as a real-mode address, usually 
pointing to a location within the DOS operati ng sys- 
tem. A virtual device driver can map the memory 
i nto conventi onal memory and change the addresses 
so that the real -mode software correctly accesses the 
caller's data. The virtual device driver should enter 
a critical section to avoid task switching while call- 
ing real -mode software that is not reentrant. 

Communication between Transient DOS Application 
Software and Global Resident DOS Software 

Most DOS application softwareand DOS TSR soft- 
ware is not designed to run in the Microsoft Win- 
dows environment. While executing, a DOS applica- 
tion is mapped into conventional memory. If the ap- 
plication calls resident software, and a task switch 
occurs while an operation is in progress, data would 
be delivered to the wrong application. 

There are two ways to handle this situation. The 
virtual device driver can enter a critical section to 
disable task switching until the operation is com- 
plete. This approach works well for synchronous 
operations that never take a perceptibly long time 
to complete. 

H owever, the system does not respond to most user 
input while the virtual device driver is in a critical 
section. Consequently, for long synchronous opera- 
tions, the end user of the application may believe 
that the system is hung. If the real-mode software 
supports asynchronous operations, the virtual de- 
vice driver can convert the operation to an asyn- 
chronous call. Handling the situation in this man- 
ner requires that a critical section be entered only 
for the time it takes to queue the call, and then only 
if the real-mode software is not reentrant. 

Support for Asynchronous Operations 

Asynchronous operations, whether in real or pro- 
tected mode, require that the virtual device driver 
be able to buffer data in a memory pool that is 
mapped i nto every vi rtual machine. In addition, the 
driver must set up a completion callback routine to 
wake up the vi rtual machi ne that made the request. 
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deliver the data to that virtual machine, and trans- 
fer control to a caller-specified callback routine, if 
necessary. 

Virtualization of Hardware Ports and I nterrupts 

Another function of virtual device drivers is to vir- 
tual ize hardware ports and interrupts so that the 
Windows system can successfully emulate several 
8086-based machines at once. Each virtual machine 
runs a DOS application that assumes it has sole use 
of a machine. DOS is a minimal operating system 
and does not provide much of the functionality re- 
quired by applications. Therefore, most DOS appli- 
cations bypass the operating system except to ac- 
cess the file system. It iscommon for an application 
to set up its own interrupt handlers and to read 
and write hardware ports. If several applications 
in separate virtual machines were to attempt these 
operations at the same time, the applications would 
interfere with one other. A virtual device driver can 
trap access to hardware I/O ports and regulate ac- 
cess to the actual hardware. 

Direct Handling of Hardware or Software Inter- 
rupts 

The virtual device driver can provide thefunction- 
ality of real-mode software. If the user has no need 
to run this software outside the Windows environ- 
ment, the software can be removed from memory. 
Removing the real -mode software reduces the need 
for context and mode switching, mapping, and copy- 
ing, and thus offers a considerable performance ad- 
vantage. If the resident software is removed, more 
memory is then available to DOS applications run- 
ning in the Windows environment. 



Virtual device drivers are debugged using the 
WDEB386 software module. This debug tool re- 
quires that a terminal or equivalent be connected 
to one of the communication ports on the PC; the 
debugger performs its I/O to that communications 
port. Symbols are available in the debugger, but 
source-level debugging is not provided. 

To take full advantage of the WDEB386 capabil- 
ities, the debug version of the Microsoft Windows 
WIN386.EXE module should be used. This version 
contains many features essential for investigating 
the behavior of the Windows system and, in par- 
ticular, for debugging virtual device drivers. The 
features include commands to display the registers, 
the stack, and the control blocks for each virtual ma- 
chine. Many of the virtual device drivers included 
with the Windows system, and the two included in 
the PATHWORKS for DOS product, have a debug 
entry poi nt that may be i nvoked by enteri ng the pe- 
ri od keyboard character, f ol I owed by the name of the 
virtual device driver. Two particularly useful debug 
entry points are .VMM and .V86MMGR, which pro- 
vide detailed information about memory usage for 
each virtual machine, including the use of expanded 
memory and the high memory area. WDEB386 can 
be used successfully in the Windows environment to 
debug virtual device drivers and to diagnose bugs in 
the read-only memory basic I/O system (ROM Bl OS) 
and other resident real-mode software. 

The CodeView for Windows debug tool is intended 
for debugging applications and dynamic link li- 
braries, not for debugging virtual device drivers. 
However, the CodeView and WDEB386 tools can be 
used simultaneously to diagnose problems that oc- 
cur when applications cause the Windows system to 
fail. 



Development Environment 

The M i crosoft Wi ndows system i ncl udes vi rtual de- 
vice drivers. Microsoft also has a device driver de- 
velopment kit specifically for developing virtual de- 
vice drivers.[l] This section describes the environ- 
ment for developing and debugging this driver soft- 
ware. 

Da/el opment Tool s 

Currently, virtual device drivers are written in 
assembly language because higher-level language 
compilers generally lack the ability to generate code 
with 32-bit offsets and registers. A special 32-bit as- 
sembler and linker are provided with the Microsoft 
Windows device driver development kit. 

Debuggi ng Tool s 
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The Network Virtual Device Drives 

The PATHWORKS for DOS software provides two 
APIs for task-to-task network communications. One 
is a DECnet socket-based interface, which uses an 
argument block called an I/O control block (lOCB). 
The other is the industry-standard PC networking 
interface, NetBIOS, with some extensions provided 
by Digital to support wide area networks. The Net- 
BIOS interface uses an argument block called the 
NetBIOS control block (NCB). Both interfaces are 
fully supported in Windows enhanced mode. 

Digital's PATHWORKS for DOS version 4.1 in- 
cludes two virtual device drivers to support net- 
working: VDNET.386, which handles DECnet socket 
calls, and VNETBIOS.386, which handles NetBIOS 
calls. Although they support different APIs, these 
two virtual device drivers are similar in structure. 
The discussion in this section applies to both drivers 
unless otherwise noted. These drivers are included 
with the current PATHWORKS version 4.1 prod- 
uct and with Windows version 3.1. To identify 
Digital Equipment Corporation as the developer of 
the drivers, Microsoft requested that the module 
names VDN ET.386 and VN ETBI OS.386 be changed 
to DECN ET.386 and DECNB.386, respectively in 
Windows version 3.1. In this paper, the nomen- 
clature VDNET and VNETBIOS is used to refer to 
these two modules. 

The drivers invoke the real -mode network software 
in the virtual machine that requested the operation. 
Creating a "network virtual machine" to which the 
driver would route all network activity would have 
allowed most of the network software to be loaded 
into a single virtual machine and thus freed up 
conventional memory for non-Windows applications. 
However, using this design would have incurred the 
overhead of switching on virtual machines for ev- 
ery network access, timer tick, and network hard- 
ware interrupt. I n addition, creating a network vir- 
tual machine would have required that the data link 
layer and the DECnet scheduler be capable of per- 
forming the virtual machine switch. Finally, this 
design would be practical only for those users who 
access the network exclusively while operating in a 
Microsoft Windows environment. 

Initialization 

Virtual device drivers are called several times dur- 
ing Windows initialization. While the Windows sys- 
tem is still operating in real mode, the VDNET and 
VNETBIOS modules check to see if the resident net- 
work software is loaded. If it is not, there is no rea- 
son to load these drivers. A value is rd:urned that 
aborts the I oad ingofthedri vers but di rects the Wi n- 
dows system to continue loading. 



After the Wi ndows system enters protected mode, 
the drivers are called again during each successive 
phase of initialization. Each virtual device driver 
takes control of the software interrupts used for its 
respective API, reserves space in the control block 
of each virtual machine, obtains parameters from 
the SYSTEM.I Nl file, and allocates a pool of global 
memory for communication with the real-mode res- 
ident networking software. Figure 2 illustrates a 
system virtual machine and a virtual machine run- 
ning a DOS application. Thefigureshowsthepool of 
conventional memory that the virtual device driver 
allocates as global memory. 

The drivers perform a "sanity check" to verify 
that the virtual device driver can distinguish global 
memory from memory that is local to a single vir- 
tual machine. However, the Windows function to 
perform this check can fail when running on some 
common unsupported software configurations. At 
this point, if the sanity check fails, the driver dis- 
plays a message to advise the user to ©(it the Win- 
dows system. 
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Figure 2 Microsoft Windows Initialization 



Virtualization cjf the Ndwcxk APIs 

When an applicaticxi issues a software interrupt 
for a DECnet or NetBIOS call, the appropriate vir- 
tual device driver gains control. If the application 
making the call is in protected mode, the virtual 
device driver always maps the call in memory. Oth- 
erwise, the driver software checks the control block 
(i .e., the I OCB or the N CB) and the buffer addresses 
to determine if they are stored in global memory, 
i.e., mapped identically in every virtual machine. If 
so, the virtual device driver does not map the call, 
because it will execute properly without mapping. 

API Mapping. If the control block and buffer ad- 
dresses are not stored in global memory, mapping is 
necessary. Thevirtual device driver allocates a hook 
control block to the operation. This control block re- 
sides in global memory and includes an lOCB or 
NCB, which the virtual device driver passes to the 
resident networking software. The driver globally 



maps the caller's buffers in the mapping-space pool 
allocated at initialization. The I OCB or NCB em- 
bedded in the hook control block contains addresses 
changed to point to the remapped address in the 
mapping-space pod. The callback (post) address 
is set to the callback routine in the virtual device 
driver, so the driver is called when the operation is 
complete. 

Optionally, if the operation is a blocking call that 
takes a long time to complete, the virtual de- 
vice driver may convert the operation to an asyn- 
chronous call. In this case, the driver sets an in- 
ternal flag, H F_Suspend_Until_POST, and does not 
return control tothe calling application until the op- 
eration is complete. All other virtual machines con- 
tinue to run while the network I/O is in progress. 
This design prevents the operation from monopoliz- 
ing the entire system. 
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Asynchronous Calls. If the call is asynchronous 
or has been converted to an asynchronous call, the 
virtual device driver must establish a callbacl< in or- 
der to be notified when the call completes. Because 
the virtual device driver runs in protected mode 
and the resident network runs in virtual mode, 
a special type of callback is required. The vir- 
tual device driver uses the Windows Allocate_V86_ 
Callback service to obtain a real -mode pointer to 
an instruction in global memory that causes a trap 
when executed in virtual mode. The Windows sys- 
tem handles this trap and transfers control to the 
virtual device driver in protected mode. 

Invoking the Ndwork Process. The virtual de- 



vice driver is now prepared to pass the call to the 
real-mode networking software. The driver enters 
a critical section to avoid reentrance problems and 
calls the Simulate_Real-Mode_l nterrupt service to 
invoke the network process as if it were being in- 
voked in real mode. The virtual device driver leaves 
the critical section when the simulated interrupt re- 
turns. If the operation is not asynchronous, the 
caller's IOCS or NCB is updated, buffers are un- 
mapped, and the hook control block is freed. Figure 
3 shows a Microsoft Windows call to the network, 
intercepted by the virtual device driver and passed 
to the network process. 
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Figure 3 Invoking the Network Process 
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Callback Routine The driver checks the 
HF Suspend Until POST flag to determine if the 
call was a blocking call that the virtual devicedriver 
converted to an asynchronous call. If so, control 
must not return to the calling application until the 
operation is complete. Normally, the callback rou- 
tine in the driver is called at this time. However, 
certain NetBIOS error conditions cause the opera- 
tion to return immediately without calling the call- 
back routine. Therefore, the NetBIOS virtual device 
driver checks the status of the call. 

if the call is still in progress, the requesting virtual 
machine relinquishes its allocated time and retries 
when the process wakes up. This design protects 



the process from being awakened prematurely by 
another virtual device driver. Also, some NetBIOS 
request errors cause the NetBIOS software inter- 
rupt to return immediately and do not transfer con- 
trol to the callback routine. Ordinarily, the process 
is only awakened by the callback routine in the vir- 
tual device driver on completion of the call. 

The Suspend_VM service can be used to block a 
virtual machine during such a call. However, sus- 
pending a virtual machine requires that the system 
call every Windows virtual device driver to notify 
it of the suspension. The notification process con- 
stitutes a high-overhead operation and is therefore 
unsuitable for this use. 
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Figure 4 Callback Routine 
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Table 1 

Flags Included in the Debugging Display 



Flag 



Indication 



HF_Wait_For_IRET 
HF_Wait_For_POST 

HF_Wait_For_Sim_POST 

HF_POST_Crit 

HF_From_PM 

HFCanceled 

HFCanceling 

HF_Suspend_Until_POST 



Cleared when the DECnet Network Process component returns to the virtual device driver. 

Set if the virtual device driver callback is required; cleared when the virtual device driver callback 
is called. 

Set if the caller requested callback; cleared when the caller's callback returns. 

Set while in a critical section. 

Set if the caller was in protected mode. 

Set if the operation was canceled. 

Set if the operation is being canceled. 

Set if the operation is a blocking call that is being simulated using an asynchronous call. 
Do not return to caller until the operation is complete. 



If the operation is asynchronous, the system trans- 
fers control to the virtual device driver callback rou- 
tine when the operation is complete, as shown in 
Figure 4. This routine calls the Windows sched- 
uler to wake up the virtual machine that requested 
the operation. The Windows event services are also 
called to invoke the event-handler routine in the 
virtual device driver when the requesting virtual 
machine is scheduled. In this way, the virtual de- 
vice driver regains control. This process restores the 
caller's context before updating the caller's data. 

As shown in Figure 4, the event routine updates 
the user's argument block and calls the user's call- 
back routine. Finally, the virtual device driver un- 
maps the buffers, frees up the hook control block, 
and returns control to the calling application. 

Virtual MachineTermination 

When a virtual machine terminates, all virtual 
device drivers are called to perform cleanup. The 
network virtual device drivers check for outstand- 
ing network operations to the virtual machine that 
is being terminated. All such operations are can- 
celed, and a warning message is displayed to the 
user. Windows applications execute in the system 
virtual machine, so their outstanding network op- 
erations, if any, are canceled when the user exits 
from the Windows system. Network operations by 
resident software are not canceled when a virtual 
machine terminates. 

Debugging Entry Points 

TheVDNET and VNETBIOS network virtual de- 
vice drivers provide debugging entry points for use 
by the Windows kernel debugger. These entry 
points give a formatted display of the hook control 
block for each hooked network call in progress. The 



display includes the requested function, buffer ad- 
dress, the handle of the virtual machine from which 
the call was requested, the virtual-machine-specific 
address of the caller's argument block, and flags. 
Theflags included in the debugging display indicate 
the state of the operation, as shown in Table 1. 

Spedal API Entry Point 

The VDNET network virtual device driver pro- 
vides an API entry point that allows application 
software to determine what version of the VDNET 
driver is loaded. This function is available to both 
protected-mode and real -mode applications. 
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Summary 

PATHWORKS network virtual device drivers ex- 
tend the Microsoft Windows enhanced mode en- 
vironment to support most hardware that can be 
installed in a personal computer. These drivers 
also support all software that can run under the 
DOS operating system, including software that by- 
passes the operating system to access the hard- 
ware directly. Networl< virtual device drivers mal<e 
network services available to the Windows kernel, 
to Windows and non-Windows applications, and to 
other virtual device drivers. The virtual device 
drivers included in the PATHWORKS for DOS soft- 
ware product permit full use of the DECnet and Net- 
BIOS APIs, including Digital-specific extensions to 
the NetBIOS interface, in the Microsoft Windows 
enhanced mode environment. 
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